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A SYSTEM AND METHOD FOR IMPLEMENTING AN AUCTION ON A 
COMPUTER NETWORK 

FIELD OF TH5 INVENTION 
5 The present invention relates to auction systems and more particularly to 

systems and methods for implementing an auction system on a network, e.g. a 
computer network or a TV network, or by means of an automaton. 

BACKGROUND OF THE INVENTION 
10 The disclosures of the following documents are incorporated herein by 

reference: 

U.S. patents 5,282,633 granted Feb. 1, 1994 to Boylan et ah; 5,083,271 
granted Jan.21 , 1992 to Thacher at aL; 5,630,757 granted May 20, 1997 to Gagin 
et al.; 4,927,156 granted May 22, 1990 to Breslow et aJ.; 5,009,429 granted April 

15 23, 1991 to Auxier; 4,637,614 granted October 18, 1985 to Gibbon et al.; 
4,261,575 granted April 14, 1981 to Corely et al.; 5,559,312 granted September 
24, 1996 to Lucero; 4,922,522 granted May 1, 1990 to Scanlon; 4,998,199 
granted March 5, 1991 to Tashiro et al.; 5,038,022 granted August 6, 1991 to 
Lucero; 5,159,549 granted October 27, 1992. to Hallman et al.; 5083,272 granted 

20 Jan.21, 1992 to Walker et al.; and 5,083,271 granted January 21, 1992 to 
Thacher etal.; 

PCT applications: WO 95/31061 filed May 5, 1995 by Catapult 
Entertainment, Inc.; WO 93/23125 filed May 14, 1993 by Codemasters limited; 
and WO 93/22017 filed April 30,1993; and 
25 European patent application 0 405 776 A2 published January 2, 1 991 . 

SUMMARY OF THE INVENTION 

In a first aspect, the present invention is a computerized auction system 
which includes the following features: auction means for processing bids 
30 communicated from participants of an auction, communicating receipts of the bids 
and status details of the auction to the participants, and determining a winner of 
th participants based on the bids received and communicating the winner to the 
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participants; bidder means for distinctly communicating to the auction means 
distinct the bids from respective the participants and processing the receipts of the 
bids and the status details of the auction communicated from the auction means; 
network means for providing communication transmission paths between th 
5 auction means and the bidder means, information communicated across th 
network means between the auction means and the bidder means being under at 
least one of a first transport protocol and a second transport protocol, the first 
transport protocol being more reliable than the second transport protocol with 
respect to insuring that data representative of the information arrives at one of the 

10 auction means and the bidder means, the second transport protocol being faster 
than the first transport protocol with respect to time elapsed for the data to be sent 
across the network means and received by one of the auction means and the 
bidder means, wherein risks associated with the information communicated under 
the second transport protocol include loss of the data during transmission across 

15 the network means, arrival of the data at one of the auction means and the bidder 
means in an order different from a temporal order in which the data were sent 
from respective one of the bidder means and the auction means, and duplicates of 
the data arriving at one of the auction means and the bidder means, the risks 
being an aspect of the auction in respect of the determining the winner of the 

20 participants. 

Preferably, the bids are communicated from the bidder means to th 
auction means under the second transport protocol, and the auction means 
includes auctioneer means for processing the bids communicated from the bidder 
means and communicating the receipts of the bids and the status details of th 

25 auction to the bidder means, the auctioneer means communicating with the bidder 
means under the second transport protocol. The auction system preferably further 
includes administrative means for processing accounts of the participants and 
processing information related to the auction apart from information 
communicated between the auctioneer means and the bidder means, and the 

30 auction means preferably includes auction support means for prompting th 
auction m ans to b gin th auction, the auction support means communicating 
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with the administrative means on a secure communications channel over a 
transmission path that is one of outside the network means and through the 
network means. 

In a preferred embodiment of the auction system, the network means 
includes at least one of a telephone network, a public mail network, a telefax 
network, a local area network, and the Internet, the first transport protocol includes 
a Transport Control. Protocol/Internet Protocol (TCP/IP), and the second transport 
protocol includes a User Datagram Protocol (UDP). 

In a preferred embodiment of the auction system, the bidder means 
communicate with the auctioneer means under auction protocols layered on top of 
the first or second transport protocols, and these auction protocols may comprise 
auction administration and bidding protocols. Further, the bidding protocols may 
preferably include parameters comprising a value for each of said bids, counts of 
messages received by said auctioneer means from said bidder means for each of 
said participants, notions of time of said auction by each of said bidder means, 
identification of winner of said participants, time when said auction started, time 
when said auction is over and a current one of said bids becomes a final bid, 
number of said bids communicated to said auctioneer means at any one time, 
number of bids each of said participants has left, how long one of said bids must 
survive to win in said auction, and number of said participants. 

In a second aspect, the present invention relates to a computer network 
auction system server which includes means for processing bids communicated 
from participants of an auction across a computer network, 

means for communicating information across the computer network to the 
participants in response to the bids communicated from the participants, 

means for determining a winner of the participants based on the bids 
received across the computer network; 

means for communicating across the computer network the winner to the 
participants; 

means for a first transport protocol under which th means for 
communicating information and the winner are carried out; and 
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means for a second transport protocol under which the bids are 
communicat d across th computer network from the participants, 
communications under the first transport protocol being more reliable than under 
the second transport protocol with respect to the communications arriving at their 
5 destination, communications under the second transport protocol being faster than 
under the first transport protocol in respect of time from initially transmitting the 
communications to arrival of the communications at an intended destination, 
wherein risks associated with communicating under the second transport protocol 
include loss of the bids during transmission across the computer network, arrival 
10 of the bids from different ones of the participants being in an order different from a 
temporal order in which the bids were sent from respective ones of the 
participants, and duplicates of at least one of the bids arriving at an intended 
destination, the risks being an aspect of the auction in respect of the means for 
determining the winner of the participants. 
15 the computer network auction server of the mentioned preferably 

comprises administrative means for processing accounts of the participants, and 
the administrative means further comprises means for processing content in a 
form of World Wide Web pages communicated to and from the bidder means. 

Preferably the first transport protocol comprises a Transport Control 
20 Protocol/Internet Protocol (TCP/IP), and the second transport protocol comprises 
a User Datagram Protocol (UDP). 

A third aspect of the present invention relates to a method for implementing 
an auction system on a communication network, which method comprises 

communicating bids by input computer equipment of respective participants 
25 of an auction across a network to auction computer equipment; 

processing received the bids by the auction computer equipment; 

providing by the auction computer equipment across the network receipts 
of the bids to the input computer equipment; 

determining by the auction computer equipment a winner of the participants 
30 based on the bids received from the input computer equipment and 

communicating by the auction computer equipment to the input comput r 
equipment the winner of the participants; 
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providing first and second transport protocols under which communications 
betw n the auction computer quipm nt and the input computer equipment are 
carried out, the first transport protocol being more reliable than the second 
transport protocol with respect to the communications arriving at an intended 
5 destination, the second transport protocol being faster than the first transport 
protocol with respect to time elapsed for the communications to be sent across the 
network and received by at least one of the input computer equipment and the 
auction computer equipment, wherein risks associated with the communications 
under the second transport protocol include loss of the communications in the 

10 network, arrival of the communications at one of the auction computer equipment 
and the input computer equipment in an order different from a temporal order in 
which the communications were sent from respective one of the input computer 
equipment and auction computer equipment, and duplicates of the 
communications arriving at one of the auction computer equipment and the input 

1 5 computer equipment, the risks being an aspect of the auction in respect of the 
determining the winner of the participants. 

Preferably the method in accordance with the third aspect of the invention 
comprises processing accounts of said participants and storing results of the 
auction. The network may comprise a public mail network, a telephone network, a 

20 telefax network, a radio network, a TV network or a computer network. 

The network utilized may comprise the Internet, the first transport protocol 
then comprising a Transport Control Protocol/Internet Protocol (TCP/IP), and the 
second transport protocol may comprise a User Datagram Protocol (UOP). 

Preferably the method in accordance with the third aspect of the invention 

25 includes carrying out communications related to the bids between the auction 
computer equipment and the input computer equipment under auction protocols 
layered on top of the first or second transport protocols. The auction protocols 
may comprise auction administration and bidding protocols. Preferably the bidding 
protocols include parameters comprising a value for each of the bids, counts of 

30 messages received by the auctioneer means from the bidder means for each of 
th participants, notions of time of the auction by each of the bidder means, 
identification of winner f the participants, tim when the auction started, time 
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when the auction is ov r and a current one of the bids becomes a final bid, 
number of the bids communicated to the auctioneer means at any one time, 
number of bids each of the participants has left, how long one of the bids must 
survive to win in the auction, and number of the participants. 
5 In a fourth aspect, the present invention concerns a method for 

implementing an auction on a computer network server, which method comprises 

processing bids communicated from participants of an auction across a 
computer network, 

communicating information across the computer network to the 
10 participants in response to the bids communicated from the participants, 

determining a winner of the participants based on the bids received 
across the computer network; 

communicating across the computer network the winner to the 
participants; 

15 communicating across the computer network under one of a first transport 

protocol and a second transport protocol, arrival of communications at an intended 
destination being more reliable but slower under the first transport protocol than 
under the second transport protocol, risk of communications being lost, delayed 
and duplicated under the second transport protocol being an aspect of the auction 

20 in respect of determining the winner of the participants. 

In a fifth aspect of the present invention there is provided an auction system 
based upon submittal of stake-supported bids from auction participants within pre- 
established time limits, the system possibly comprising a communication network 
for communication between an auctioneer and the participants, the auction system 

25 comprising 

- interface means adapted for presenting bids from the participants, 

- a detector means for detecting bids submitted from each participant, 

- a real or simulated clock situated with the auctioneer for marking the start 
and end times for an auction, recording running auction time as well as time points 

30 for bid detection in the detector m ans, and 

- a decision means for deciding on an auction result, the audi n result being a 
function of th bid time points. 
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Preferably, the decision m ans is adapted to t st wh ther a predetermined 
time period, or a time period variable according to predetermined rules, has 
passed after the last detected bid without detection of a new incoming bid, and if 
this is the case, to identify the participant with the last detected bid as an auction 
5 winner, and if this is not the case during the total auction duration, to identity the 
participant having submitted the last bid before the auction end time, as a winner. 

The interface means may be computer terminals attached to a real time 
data-transmitting communication network, possibly via modem, and the auctioneer 
then attached to the same network by means of a computer terminal in a similar 
10 manner. Further, the auctioneer clock, the detector means and the decision 

means may then be comprised in an auctioneer computer adapted to manage an 
auction in accordance with programmed auction algorithms. 

The auctioneer computer algorithms are preferably adapted to manage bids 
submitted in real time from the participants during the course of the auction. In a 
1 5 specific embodiment, the computer may even be adapted for possible correction 
due to transmission delay from the computer terminals of the participants. 

One of the auctioneer computer algorithms may be an algorithm for varying 
the length of the time period to "hammer down" as a function of elapsed auction 
time or as a function of the current bid submittal rate from the total of the 
20 participants. 

In order to present to each participant the running auction progress and 
activity, the participant computer terminals and also the communication network 
may be adapted for transmission of real time information from the auctioneer 
computer. 

25 In a special embodiment, the auctioneer computer algorithms may be 

adapted to manage bids submitted in a group from each participant within a fixed 
point of time, so that when this point of time has passed, the computer can 
immediately simulate the total course of the auction. 

The total number of bids during the auction may be predetermined, and the 
30 auctioneer computer algorithms are then adapted to manage bids submitted from 
ach participant at the same time as the participant mak s entry for the 
aucti n/pays the bids. 



CA 02311353 2000-05-23 



W 99/27476 PCI7NO98/00348 

S 

Alternatively, if no limit is set for th total number of bids during the auction, 
the auctioneer computer alg rithms will be adapted to manage a) auction 
entry/payment of bids from each respective participant within a predetermined 
point of time, b) thereafter calculating the total auction time, i.e. the time span from 
start to end time, c) establishing a time limit for submittal of grouped bid times, 
from each respective participant and (d) subsequent to reception of bids from the 
participants and expiry of the time limit, simulation of the total course of the 
auction. 

The auctioneer computer, the participant computer terminals and the 
communication network may further be adapted for transmission of information 
about the simulated course of the auction to each respective participant, possibly 
in the form of a screen presentation of the auction course in a real or transformed 
time scale. 

In an even further specified embodiment, the auctioneer computer may also 
be adapted to transmit in accordance with special programming, side information 
to the participant computer terminals, (a) the side information being controlled 
during real time or simulated auction progress by the auctioneer clock and 
possibly by the running auction development, for initiating picture/sound 
presentation or short film of a type which is auction related, entertaining or 
distracting, next to or "behind" the auction information, in order to increase the 
auction attraction, and (b) the side information comprising, during phases with 
entry/payment/pre-bidding, animations containing entertainment or auction related 
information or possibly advertising. 

In an alternative embodiment of the auction system of the fifth aspect, the 
auctioneer computer may comprise a memory for storing a total auction course, so 
that a participant may have data concerning the auction course presented in his 
computer terminal automatically or on request after a finished auction. 

In an embodiment of the fifth aspect of the invention, which embodiment is 
directed to an auction performed by means of an automaton, at least one 
participant is a genuine participant and a plurality of participants is a number of 
simulated participants, the system further comprising auctioneer random 
generator means controlling the number of and bidding tim s for simulated 
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participants in accordance with predetermined random generator algorithms, the 
algorithms containing parameters adjustable so as to tun auction winning 
probability into a range that is compatible with national law. 

In a preferred embodiment of the auction system of the fifth aspect, the 
5 communication network may be devided in two parts, 

part of the communication network may be any of a public switched 
telephone network, a cellular network, a computer network and a reverse TV 
channel network, 

the interface means may be any of telephones, cellular phones, telefax 
1 0 units, computer terminals, and TV sets having two-way communication 
capabilities, 

the auctioneer may be broadcasting any of a radio program, a TV program 
and a text TV program via another part of the communication network, which other 
part is constituted by any of a public radio channel, a TV channel and a closed- 

15 circuit network, in which radio/TV/text TV program real time information is 
transmitted regarding auction progress. 

In a completely different embodiment of the auction system in accordance 
with the fifth aspect of the invention, the interface means are coupons to be 
completed by each participant and sent to the auctioneer, a coupon containing 

20 information about the desired bid time points for the participant in question within a 
pre-established time frame, and with a number of bids fixed according to rule and 
according to stake, the detector means is a coupon reader unit, the decision 
means is a preprogrammed computer attached to the coupon reader unit, and the 
clock is a simulated clock according to which the bids from the participants are 

25 ordered chronologically, the communication network being a public mail network, 
a telephone network, a telefax network or a computer network. 

In a sixth aspect of the invention, there is provided a method for an auction 
based upon submittal of stake-supported bids from auction participants within pre- 
established time limits, the auction comprising the steps of: 

30 presenting to an auctioneer bids from the participants via at least 

interface m ans, 
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detecting by auctione r bid detector means bids submitted from any 
participant 

using a real or simulated clock situated with the auctioneer for marking 
start and end times for the auction, and for recording running auction time as well 
as time points for bid detection by the auctioneer bid detector means, and 

deciding on an auction result by an auctioneer decision means, the 
auction result being a function of the bid time points. 

Preferably the auction method also comprises testing whether a 
predetermined time period, or a time period variable according to predetermined 
rules, has passed after the last detected bid without detection of a new incoming 
bid, and if this is the case, identifying the participant with the last detected bid as 
an auction winner, and if this is not the case during the total auction duration, 
identifying the participant having submitted the last bid before the auction end 
time, as a winner. 

BRIEF DESCRIPTION OF THE DRAWINGS 

In the following a more detailed description of the invention is given, 
referring also to embodiment examples illustrated in the appended drawings, 
where 

fig. 1 shows schematically basic elements of a computerized auction 
system in accordance with a first aspect of the invention, 

fig. 2 shows hardware and software platform characteristics of network 
servers constituting an essential element of the computerized auction system in 
accordance with the first four aspects of the invention, 

fig. 3 shown hardware and software platform characteristics of network 
clients which constitute another essential element of the computerized auction 
system in accordance with the first four aspects of the invention, 

fig. 4 shows an auction system overview in accordance with the first aspect 
of the invention, 

fig. 5 is a flow diagram illuminating som necessary steps in a method in 
accordance with the inv ntion, 
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fig. 6 is a communication chart showing conn ctions between any client 
and the auctioneer gam engine, 

fig. 7 is another communication chart highlighting connections between 
auctioneer servers and the closest part of the communications network, 
5 fig. 8 illustrates what happens in a real time version of an "American 

auction", 

fig. 9 illustrates what happens in an "instant" version of an "American 
auction", 

fig. 10 illustrates what happens in a "strategic/simulation" version of an 
10 "American auction", 

fig. 1 1 shows in a schematicaJ manner all possible communication network 
connections between objects participating in an auction in accordance with the 
invention, and 

fig. 12 shows an example of a bid board display for an auction participant in 
IS a sealed bid type auction. 

DETAILED DESCRIPTION OF THE INVENTION 

Fig. 1 is a simple illustration of general features of the computerized and 
network-based auction embodiment of the invention, in which embodiment the 

20 auctioneer uses at least two network servers as shown in the left part of the 
drawing, of which one server is mainly an administrative server for processing 
participants' accounts and related information, while the other server processes 
bids communicated via the network from the participants, as well as 
communications to the participants regarding running auction status details. 

25 The figure further shows examples of participant PC-s and the 

communication network in general. 

Fig. 2 deals with examples of required hardware and software platforms for 
the two necessary network servers. The drawing is text-based and self- 
explanatory, and the text thereof is hereby incorporated. 

30 Fig. 3 deals with examples of required hardware and software platforms for 

participant PC-s, and the drawing t xtual and self-explanatory. The text is 
incorp rated herein. 
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The original auction concept at the outset being a network dependent 
invention, can asily be adapted to cover a much wider market segment, 
adaptation La. as follows: 

"game-boy" type machines 

distributed via CD's/simulation 

automatic game machines 

advertising tools/auctioning 3 rt party company products. 
The inventor believes that this will enhance, at low cost, the value of the invention. 

The basic, underlying concept "American Auction" is a concept where 
strategic skills are important for winning the auction. Participating will also 
enhance the strategic (and analytic) skills over a period of play, improving the 
participant's general strategic skills in his normal life/work situation, thus having 
major educational and competitive elements. Last, but not least, the participation 
is entertaining via the excitement of the actual auction, and the various supporting 
themes. 

Strategy , education and entertainment are the three most important 
attractive/selling features of the auction concept, and will (have to) be present in 
all versions of the invention. As the focus has been on these features while 
developing the Auction concept, we believe that these are present as an 
integrated part of the concept. 

While, however, different market segments/populations have varied focus 
on these elements, it is important to "tailor" products/themes and actual medium, 
in addition to segmentation according to stake/pot size. 

By doing this, the auction organizer will be able to cover a vast market, covering 
both high/low "status" markets, also competing with more traditional game 
machines, "game boy", pure entertainment games (PC and/or Internet based) etc. 

It has also become clear to the inventor, that the Auction well may be an 
excellent marketing tool for Computer/Internet related (as well as non-related) 
companies in advertising and selling their products through selling licenses and 
arranging auctions for th se companies where their products are the auction pot 
Such auctions may be distributed via CD (through PC magazines or otherwise), or 
via a look-up through a web browser or company horn page. It is felt that this 
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idea has a major potential f r being a new marketing/advertising concept, where a 
product can be prominently displayed to an attentive audience for a long period of 
time. 

The concept can be used in a number of "spin-off' products highlighting 
strategic, educational and/or the entertainment features and variants of same. 

1. "Game boy" type palm-held machine where the competition is simulated by 
selected number of participants (competition), number of competing/own 
bids and a varied number of bids per participant/groups of participants. This 
flexibility will give different degrees of difficulty the same way as current 
"game bey 1 machines, but with totally different features through themes, 
strategy and entertainment value. Game pot in the form of points. 
Entertaining themes, however, simpler artistically, due to limited capacity. 

2. CD, or Internet distributed simulation auctions (with same features as the 
"game boy" version), but with a more sophisticated animation and choices, 

IS to be distributed (for CD's) via PC Magazines/Mail etc. and to be played via 

own PC. 

This product may be excellent as an enhancement of the animations of the 
original Auction concept as well as being a stand-alone product for 
entertainment as well as training for the actual Coin Auctions. 
20 These CD/Internet distributed simulation auctions are also excellent media 

for advertising (see above). 

3. Automatic game machines/Simulation of competition. 

Same concept as 1 and 2 above, but with winning pot. Such an automaton 
auction concept would be covered by Games Legislation in many countries. 
25 The pot would be dependant on the chosen degree of difficulty. 

This product will compete directly with the current game machine market, 
and licensing to current operators should be considered. 

4. Auctions arranged for the purpose of advertising products, where 
pot/auction object is the advertising company's product/products. 

30 Distribution both via Internet and CDs. 
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First preferred Pmh odim nt of the invention: 

A $VStem for conducin g an "American Auction" across an int met 

American auction resembles an ordinary auction, where players make bids, 
and rf a bid is unchallenged for some period of time the last bidder wins. However, 
in this auction all bids are the same "size", players pay for each bid they make, 
and the player who makes the last valid bid Is the winner. 
It is referred in general to figs. 1-8. 

The auctioneer uses, or preferably is a program which handles incoming 
bids from authorized bidders. The program runs on a machine with an internet 
connection. The bidders must use machines with access to the same internet that 
the auctioneer is connected to. The machines must be equipped with a WWW 
browser which can down load and execute Java applets. All participants in an 
auction communicate with the same (single) auctioneer using special "auction 
protocols" layered on top of the standard Internet Protocols. 

Fig. 4 is an overview of an embodiment of the computerized auction system 
of the invention. First level parameters are auction rules, auction protocols, system 
capacity, performance/optimizations, auction operation and security issues. 

On a next level the auction protocols are divided into an auction 
administration protocol and a bidding protocol that are handled separately. 

On a next level below the performance/optimizations level, one aspect is 
the avoidance of data conversions, and another aspect is reduction of message 
traffic. 

Under the security issues there are aspects related to initialization, bidding, 
overload and result distribution. 



1- The Rules (see fig. 5) 
1.1 Preliminaries 

• there are N players 

• each player must buy at least min bids, before the auction starts 

• there is currently no maximum limit on the number of bids a player 
buy 

• a player cannot buy more bids once an auction has started 
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1.2 Startup 

• Players must decide if they want to pfay before the auction starts. 
(Otherwise players could watch the auction, and join fate without risk and 

5 with an added chance of winning.) 

• It should be possible to rejoin the auction after the auction has started 
(client machines will crash). 

• During demos players will be allowed to log in at any time. 

10 1.3 The Play 

• players are notified whenever a bid is made 

• whenever a player makes a bid, a clock is started 

• if timeout seconds elapse without further bids, the player who made the 
last bid is declared the winner 

15 • there is an (imposed) upper limit on the duration of a auction, probably 

between one and two hours 

• the timeout decreases as the auction grows older 

There is a chicken and egg problem at the start of the auction, when no 
one has made any bid, and there is no winner. It is possible to set the initial 

20 timeout to the entire auction duration, and reset it to a "normal" value when the 
first real bid arrives. This works well for demo purposes, but is probably not 
suitable for a real auction. Another solution is to set the initial timeout normally, 
and if no one has made a bid during the first timeout seconds, the organizer of th 
auction is the winner. A third solution is to have a "house player who gives a 

25 single bid sometime at the start of the auction, and is quiet thereafter. The house 
player wins on behalf of the auction organizer. 

The auction needs to stop some time. Assume there are 3600 players, 
each with 10 bids available. With a timeout of 10 seconds, a worst case auction 
will last 100 hours, which is clearly not acceptable. 
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In one mbodiment, the timeouts are d creased linearly as the auction 
grows older. However, the timeout cannot be a Hosed to approach zero, so that the 
round trip time becomes greater than the timeout. A timeout lower limit must be 
set, or one solution might be to publish a deadline for each auction. If the auction 
reaches the deadline without having established a winner, the Xth bid to arrive 
after the deadline becomes the winning bid. 



1.4 Payoff 

• unused bids in excess of min are returned to the players 

• collect penalties each player must pay for at least min bids 

• the auction organizer takes a cut (e.g. 20%) of the total income, the rest 
(the pot) is paid back to the participants (winners) 

• players who have not made any bids get nothing 

• the winner gets some fraction prize (e.g. 80%) of pot 

• the winner gets all his bids refunded (if possible) 

• while there are money left the players who have made fewest bids get a 
refund of their made bids (not their penalty bids) 

• any excess (round off errors etc.) go the auction organizer. 

2. Auction Protocols 

The protocol may e.g. use ASCII text encoding. Each message consists of 
some number of fields, separated by blanks. The first field is a single "tag- 
character which identifies the type of the message. 

2. 1 Auction Administration 

It is . convenient to use a reliable connection for the administrative 
commands, Login and Quit. 

Referring to fig. 6, when a participant wishes to send an administrative 
command (Login or Quit), he (the client) should follow the following steps: 

1. open a TCP connection to Auctioneer server/Game engin (using 
th sam port number as th UDP connection for bidding uses). 

2. format and write the command to the conn ction 
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3. read the response (or possibly " nd of file") 

4. clos th connection 

In fig. 6, lower part, are shown two sequential access storage media, i. 
one containing data regarding legitimate participants (players) and one for storing 
5 logs, both connected to the administrative network server. 

It is assumed that the administrative system distributes a client code to th 
participants, together with a "name" and (eventually) authentication information, 
encryption keys etc. 

At the start of the auction the participant must log on to the server with a 
10 Login mesage. The server (auctioneer) will reply with an Accept message or an 
Error message. 



15 



20 



25 



Login ~ L name port 

Accept = A winner start now deadfine bidsmade bidsleft timeout who serial 
Error = E string 



name 

port 

winner 

now 

start 

deadline 

serial 
bidsmade 
bidsleft 
who 

timeout 



an alphanumeric string 

the UDP port the client whiches to use 

the id of the current winner 

the auctioneer's idea of the current time 

when the auction started (if start > now the auction has not started 
yet) 

auctioneer's notion of time when the current bid becomes final (if 

deadline < now the auction is over) 

the serial number of the message this is a reply to 

how many bids have been made so far (total) 

number of bids the player has left 

numeric id the player should use in remaining communication with 
the server 

how long a bid must survive in order to win 
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When a participant detects that the auction is over, he should ask for 
results by sending a Quit m ssage. The server wiil reply with either a Payoff 
message, a Wait message (if the auction is not over yet), or an Error message. 



5 Quit « Q who 



Payoff = P who result bidsmade bidspaid 



Error = E string 



Wait = W 



who 



numeric id 



10 result 



net amount won (or lost if negative) 



bidsmade number of bids seen by the server 
bidspaid number of bids the player must pay for 

2.2 Bidding Protocol 
15 It would be preferable to have a reliable real time communication channel 

between the auctioneer and the participant throughout the auction, but the Internet 

protocols can not provide this. 

Instead UDP is preferably used as the transport protocol for the bids. This 

means that messages can get lost, they can arrive out of order, and they may be 
20 duplicated. 

Message delays and message loss should be considered part of th 
auction, and an aspect of the auction that participants should be aware of. 

The auctioneer measures time in seconds since auction start. The 
auctioneer's notion of time is the one that counts. 
25 The participants can announce that they are still alive, and they can mak 

bids. 

Bid = B bid serial who now 



bid 



takes the values 0 ("I am here H ) or 1 ("I want to make a bid") 

each participant keeps a count of how many messages he has sent, 

th first m ssage has s rial number 0 



30 serial 
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each participant gets a unique (numeric) identification at auction 
start 

the participant's notion of auction time (unused by the auctioneer so 
far) 

The client program should probably send empty bids at "slightly random" 
regular intervals, perhaps something like an average of two messages per minute. 

The auctioneer sends a Receipt for every message it receives from a 
player. The auctioneer broadcasts a Status message whenever he receives a new 
bid (and possibly at other times as well): 



WO 99/27476 

who 
now 



Receipt = R winner start now deadline bidsmade bidsleft serial who when 
Status = S winner start now deadline bidsmade timeout max 



winner 

now 

start 

deadline 

serial 

bidsmade 

bidsleft 

who 

when 

timeout 

max 



the id of the current winner 

the auctioneer's notion of current time 

when the auction started (if start > now the auction has not started 
yet) 

auction time when the current bid becomes final (if deadline < now 
the auction is over) 

the serial number of the message this is a reply to 

how many bids have been made so far (total) 

number of bids the participant has left 

numeric id of participant 

the 'now* value of the bid this is a reply to 

how long a bid must survive in order to win 

number of (potentially) participating bidders (this should probably be 
the number of "active" participants, and perhaps it should only 
include participants with bids left) 



seen, 
the s 



For each participant, the auctioneer will keep track of the serial number last 
When the auctioneer receives a bid (or an "I'm here" message), it will check 
rial number of the new message against the saved serial number. 
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• If the new serial number is greater than the saved one, it is accepted, 
analyzed, and replied to. 

• If the new serial number is less than or equal to the saved number, it has 
h arrived out or order (or it may be duplicate). The message is ignored 

5 (and not replied to). 

The client should probably compute a running estimate of the round trip 
time, and it is probably a good idea for a client to synchronize it's notion of tim 
with that of the auctioneer. 

It is the auctioneer's count of the number of bids made by a participant 
10 which counts. The client should probably keep track of the last message it has got 
a receipt for, and attempt to synchronize the local count of the number of bids 
made, with that of the auctioneer. The client program should probably not prohibit 
the participant from sending more bids than the participant is supposed to. 

15 3. Capacity 

Each participating bidder should get a notification of new bids "immediately 1 ' 
when a new bid is accepted from a legitimate bidder. Such notifications ("status 
messages") are ASCII text messages, they are small (less than 100 characters), 
and the content is not secret 

The time from the auctioneer gets a new bid until it can start broadcasting 
status messages is negligible compared to the time it takes to do the broadcast 

A machine which executes the auctioneer program should have the 
capacity to send the same (small) message to N different UDP addresses in the 
course of S seconds, where N is the number of participating bidders, and S is an 
acceptable approximation of "immediately". 

The status message will be sent to one bidder at a time, so that the delay 
(from the auctioneer) will be 0 for the first bidder and S seconds for the last. 

The bidders will in addition experience network delay. It is hard to predict 
how much delay will be acceptable to the bidders. One might guess that a total 
delay of less than 1 second is mor than good enough, while delays greater than 
4 seconds will be unacceptable. 
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Tests have been performed using Sun Sparcstation 20 machines running 
Solaris 2.5. It seems that thes can send somewher b tween 1000 and 2000 
UDP messages per second. 

5 4. Performance and Optimizations 

4.1 Avoiding Data Conversions 

Messages and logs are textual, all numbers are transmitted in decimal. This 
is good for debugging purposes, but the server will spend a fair amount of time 
converting between binary data and textual format Either binary formats or 
10 special purpose textual routines could improve speed. 

4.2 Reducing Message Traffic 

Clients should send few "I'm here" messages. Clients will probably receive 
sufficient number of Status messages to stay reasonably updated. 
15 Sending Status messages to all clients is the main bottleneck. IP multicast 

would probably remove this bottleneck, but is unfortunately not generally 
available. 

One should try to avoid "useless" status messages, for instance by trying to 
detect if a batch of bids arrives at more or less the same time, and send a status 
20 message only when the last one has been processed. 

If the load is very high, and there is a batch of bids coming in, one could 
quietly "drop" all bids but the last (players would gain by this). 

If the load is high, try to avoid sending Receipts for non winning or empty 

bids. 

25 One could let the server send "unsolicited 11 receipts if it has dull periods. 

5. Running an auction 

A real auction should be handled using (at least) two web servers, see 
figs. 1, 2 and 7. 

30 In fig. 7 is shown an example of connections between the closest central 

Router in the netw rk and the auction servers. An administration s rver has a two- 
way conn ction to th network, operating under a first transport prot col that is 
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reliable, however not necessarily v ry fast. This s rver is able to present a WWW 
menu leading to a demo, a log on possibility for a participant, oth r types of 
information, and a credit cheque feature is also included. 

The administration server provides user names, passwords etc. for an 
auction server that has another type of connection to the network, i.e. a 
connection operating under a faster, but less reliable transport protocol. This fast 
connection takes care of the actual real time bidding process in which messages 
(bids) must be conveyed rapidly to the auctioneer, as well as receipts to the 
participants. 

A third auctioneer server has also been included in the drawing, which 
server takes care of messages that are common to all participants, and may 
operate under the first mentioned transport protocol. 

The main administrative server handles accounts, auction information and 
web pages, and should not execute on the same machine as the auctioneer. 

A "small" web server must execute on the same machine as the auctioneer, 
This server communicates with the main server across a secure channel, and has 
the following tasks (see also fig. 2): 

• on request send Java code to legitimate auction participants (bidders) 

• start the auction program (the auctioneer) at the correct time with the 
correct parameters 

• save the result of an auction (logs and payoff matrix) 

The auctioneer is preferably a normal Unix program, and can be started 
from the command line: 

• auction options 
The options are: 

- 1 string set log-prefix to string. As a special case, if log-prefix is not set, all 

logs go to standard output 
- b file name of a file of legal bidders, no file implies demo mode. This file is 

currently an ASCII text file, containing one line for each legal bidder. 

Each line consists of at least two fields, separated with whitespace. 

The first field is the name of the bidder. Th second fi Id is the 
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maximum number of bids this bidder is allowed to make. Further 
fi Ids are currently ignored, but are xpected to contain security 
information (keys, passwords). 



-pporf 



number of the port to use. The same port number is used for UDP 



and TCP. The current default is 6010, which is a fairly random 
choice. 

- s time when the auction starts. Currently two formats are accepted: +/? 

starts in n seconds, or h.m starts today at h.m o'clock. Current 

default is +1 (start after 1 second), 
-d minutes how long the auction lasts. Current default is 20 minutes. 
- 1 seconds initial timeout (default is 20 seconds). 

•mmax default max number of bids per bidder when running demos 



The auctioneer prints a list of authorized bidders before the auction starts 
(a requirement for accounting and audit reasons). The first line identifies the 
auction, the second is a comment, and the remaining lines are one for each 
bidder. 

Each line contains a numeric id, the name of the bidder, and the number of 
bids he has available. 
Example: 

# ./auction (0.9) 1997/11/17/10.19.36 = 000879760176 castor 

# id who bids 
000000 . 0 

000001 Eigil B 

000002 Tom 6 

000003 Eirik 8 

000004 Brynjulv 8 



-D 



(default 8). 

demo mode, allow anyone to fog in (implied if no -b option) 
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During the auction, the auctioneer prints interesting v nts to a log file. 
Each line starts with a "time-stamp", which is the current auctioneer time (in 
seconds since some reference time), followed by a "serial number within each 
second. 

5 Log fines are either Comment lines, Login lines, Quit lines, Bid lines or 

Status lines. Status lines are printed whenever a new status message is 
broadcast. 

Comment * time-stamp # comments 
1 0 Login = time-stamp L id port name addr result 
Bid = time-stamp B bid id serial time disp 
Status = time-stamp S winner left timeout total 
Quit = time-stamp Q id 



Id numeric id 

15 winner the id of the current winner 

port which port the bidder wishes to use for status messages 

name real name of bidder 

addr internet address of bidder 

result one of "ok", "no" or "late" 

20 serial serial number of the bid 

bid 1 (real bid) or 0 (no bid) 

time bidders notion of time (unused by auctioneer) 

disp how the bid is treated 

(emptyBid/GameOver/waitABit/noneLeft/Accepted) 

25 left time left until deadline (from timestamp) 

timeout current timeout value 

total total number of bids made by all bidders so far 



CA 02311353 2000-05-23 



WO 99/27476 PCI7N098/DG348 

25 

An xample xcept; 

0879760175.00000 # ./auction (0.9) 1997/11/17/10.49.36 = 000879760176 castor 

0879760177.00000 # NOTSTARTED -> RUNNING 

08797601 77.00001 S 000000 1 1 99 020 0 

0879760179.00000 L 1 43391 Eigil 156.116.2.222:43391 ok 

0879760179.00001 B 1 00001 000000 879760179.854896 accepted 
0879760179.00003 S 000001 020 020 1 
0879760180.00021 B 1 000004 000008 879760180.886145 noneLeft 

0879760238.00001 # result printed 

0879760238.00002 S 000002 -01 019 32 
0879760243.00000 Q 000001 
0879760249.00002 # auction over : 879760237 

After the auction is over, the auctioneer prints a result file, which consists of 
an initial identifying line, then a header line, followed by one line for each active 
bidder. Each line contains the bidder's numeric id, the bidder's name, the net 
result, and the number of bids made. 

Example: 

# Vauction (0.9) 1997/11/17/10.49.36 = 000879760176 castor 



# id who result bids 

000000 . 0 0 

000001 Eigil -8 8 

000002 Tom 17 8 

000003 Eirik -8 8 

000004 Brynjulv -8 8 
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6. Source Code 

# date 

FriNov 7 13:18:45 MET 1997 

# wc bids.c commands.c tog.c main.c payoff.c player.c rungame.c util.c game.h 



137 


481 


3152 


bids.c 


135 


425 


2783 


commands.c 


39 


104 


765 


log.c 


164 


650 


4813 


main.c 


113 


446 


2477 


payoff.c 


108 


426 


2732 


player.c 


200 


640 


4643 


rungame.c 


133 


439 


2954 


util.c 


128 


541 


3287 


game.h 


1157 


4152 


27706 total 



main.c main prog ram for the auctioneer 

rungame.c actually run the auction 

bids.c handle incoming bids 

commands.c handle incoming (tcp) commands (logon and quit) 

payoff.c implements current rules for payoff at end of auction 

player.c read/create player data structures 

log.c implements logging functions 

util.c various utilities 

game.h contains common typedefs and declarations 

cllentc a program which creates one or more clients 



7. Security Issues 
7.1 Initialization 

It is here assumed that the auctioneer program will be started by a minimal 
web server running on the same machine as the auctioneer. 

This minimal web server will communicate with th main administrate web 
server using SSL, and will deliver Java code to auth nticated clients (participants). 
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7.2 Bidding 

During the auction the participants send Bids, and the Server sends 
Receipts and Status messages. Message loss is part of the game. 

Cheaters may attempt to listen to message traffic they are not entitled to 
see, they may attempt to inject false messages into the message streams, they 
may resend genuine messages, or they may push "junk bytes" into the message 
streams. 

Authentication and encryption techniques can be used to ensure the 
integrity of messages, at a possibly substantial cost in processing time. 

The simplest approach is to have the auctioneer share a secret key with 
each player. This key is used to encrypt and decrypt Receipts, Bids and Status 
messages. 

There does not seem to be any compelling reason to keep the content of 
messages secret. If this is so, it is sufficient if we use the key to attach a signature 
to each message. 

7.3 Overload 

One possible attack could run as follows: A participant decides to bid. As 
soon as she gets a receipt she activates one or more programs which attempt to 
block other participants from getting their bids through to the server. These 
programs could send as much junk data as possible to the auctioneer. 

A possible counter to this sort of attack is for the server to slow down the 
clock if it receives a burst of junk. 

7.4 Result Distribution 

The server writes the result and the log to files, e.g. sequential files as 
shown in fig. 6. Administrative routines must ensure that these files are kept as 
long as needed, and that they are not tampered with. 
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8. Further preferabl features 

• The Auctioneer should minimize the number of status messages s nt 

• The Auctioneer must provide signed (or possibly encrypted) messages. 
There are public domain C implementations of MD5 which can be used 
as a basis for signing messages. 

• The Auctioneer must handle overload gracefully. A suitable strategy for 
this must be specified and implemented. 

• It must be possible to ensure that auctions finish in a reasonable amount 
of time. A strategy for timely termination of an auction must be specified 
and implemented. 

FURTHER AUCTION EMBODIMENTS 

A) "REAL TIME" - Interactive, see fig. 8. 

Fig. 8 relates to the real time embodiment of the computer network auction 
system. A clock symbolizes the starting time of the auction, prior to which time 
participants must have signed on and bought a predetermined number of bids. 

The "rolling film" symbolizes the running auction time period, during which 
any participant may place his successive bids at successive points of time to stop 
the "auction hammer" from falling all the way down. The rolling film may also 
symbolize a log of the auction progress, which log can be "replayed" at a later 
time. 

The real time auction is played interactively in "real time" starting at a fixed 
time and ending when one participant wins. (Exactly like a "normal" auction.) Bids 
are bought ahead of time, and used during the auction at participant's option. 

The length of the auction depends on the allowed number of participants 
and bids per participant. Theoretically, the auction may be never-ending, therefore 
it is important to limit auction time by limiting number of bids (participants and/or 
bids). Likely maximum is 2500 bids (say: 5 bids and 500 participants) 
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The auction does not start unless bidding starts. It is unlikely that anybody 
wants to be the first bidder. Therefore th auction machin has one bid which is 
used to start the bid process (1" bid only). 

A bid wins as long as no other bids come in within a set number of 
seconds. At the outset this time period is planned set at 30 seconds. (As 
visualized by timer count-down meter ("auction hammer falling") presented on 
participants' PC screens.) 

To limit total auction time, this variable (30 seconds until winning) may be 
reduced to 20 sec. and 10 sec. a certain time into the auction, which also 
increases the intensity of the auction and the nervousness of the participants, thus 
over-proportionately reducing auction time. 

Safetv/securitv features, how to pre vent or counteract jamming. 

The net work auction must be protected from unauthorized activities from 
participants, and one should also create procedures to be followed in case of 
technical breakedown/loss of a significant number of participants. 

In case of a technical breakdown, i.e. the loss of contact with a certain 
number (major number) of participants, and/or the server is in an "overload" 
situation, the auction will be stopped. A random number of bids will then be 
"erased" as legitimate bids, and returned to the bidders. In this way, nobody can 
predict which bid was the last bid, in case of manipulation. After a "clean-up M , i.e. 
when on-line access has been re-established, the auction restarts. 

The auctioneer shall have on-iine contact with at least n% of the 
participants at any time. When this limit is crossed, the auction stops, contact must 
be re-established, and the auction then continttas. 

Regarding the problem of jamming, a safety precaution for the auction, and 
a precaution against manipulation, is a function where the '^java-applet" on the 
client PC continuously sends (fake) messages as an "on-line check". For an 
outsider/manipulator, these checks are impossible to distinguish from real bids, 
which complicates a possible manipulation effort. Further, traditional "fire-walls" 
will be implemented f r the aucti n server, and the highest approved security in 
coding will b implement d. At present, a 56 bit DES-atgorithm is approved for 
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commercial applications from th US. This security code compares to codes 
currently us d by e.g. th Bank of Norway. 

To eliminate a bidder with a certain jamming strategy, the auction may be 
stopped in the same manner as described above, a random number of bids will b 
cancelled to eliminate the jamming bidder, and the game will then be restarted. 

Optional features: 

All of the three below items will have (be perceived as having) 
entertainment value for the participants and set the auction above other games: 

• Interactivity 

• Design 

• Strategy game (log - analysis of individual strategy compared to other 
participants/winner after auction end - or alternatively during auction) 

- Interactivity 

The auction has full "real-time" interaction as one sees all actions of other 
participants, and your own actions are re-action to this. 

- Design 

Pure entertaining features are presented as background design visualizing 
the action of the participants via theme-stories. The story must reflect the action of 
the participants, i.e. also be interactive with the auction-action. The themes may 
be "auction-theme with auctioneer, gold-coin machine etc.", dragons and 
dungeons, war-game, etc., i.e. the themes may be unlimited as long as theme (or 
action within the story) may easily reflect the auction-action. 

Another feature is that a participant may choose from a range of 
background stories, the one to his liking, which gives him/her most excitement. 

- Strategy 

One may choose different strategies for participating in the auction. The 
(ultimate) point of the auction is to have the bid surviving for 30 seconds (or as 
long as the auction-rule specifies for a winner). 

B low we will try to present strategies as we see them presently, by 
indicating in a table individual participant's chances to win as affected by oth r 
participants' strategy: 
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Individual strategy: 




Action 


Non-Action (wait) 


Other 

participants' 
strategy: 


Action 


Reduced chances 


Increased chances 




Non-Action 


Increased chances 


Reduced chances 




Alternative results for individual participant: 




• Winning (others 
dont bid} 

• Loosing (no more 
bids) 

• Remaining in 
auction 


• Loosing (other 
winner) 

• Surviving (others 
bid) 

• Winning (bids left 
when others have 
none) 



One will see from the above table that it is important for the winning 
chances that the participant is counter- H cyclicar to the "mainstream" strategy. The 
5 strategy may have to be different for the different periods of the auction 

(beginning/middle/end), as one may see a "non action" strategy in the beginning, 
and an "action" strategy towards the end, so one should actually plan more than 
one strategy for each individual auction. 

An auction-log comparing individual participant's strategy with average 
1 0 participantfwinner will give feedback for strategy in a next auction. This, we 

expect, will be perceived as "educationalTa learning experience", and definitely 
entertaining, even if a winning strategy for on auction may be a loosing strategy 
for the next one. 
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Lastly, the auction log may be used to define: 

1. 2*"/$" place (after winner) 

2. winner strategy 

3. optimal strategy - early/middle/late auction 

4. total time in winning position 

5. how many bid-rounds you have waited out ("stayed cool") 

6. how many bids given at the same time 

A limited number of participants give high winning chances compared to 
most other game types, thus giving a high attraction value. 
Market segmentation: 

1**tier segmentation : Participants must have access to PC or another type 
of interface equipment. 

2 nd tier segmentation : Cost of bids. (I.e. covers affluent and average 
segment based on this variable). 

Examples: 

Affluent: 100/1000 USD bid (total cost at 5 bids/auction 500/5000 USD auction) 
Average: 1/20 USD bid (total cost at 5 bids/auction 5/100 USD auction) 

B) SIMULATION 1 Non interactive, see fig. 9. 

Fig. 9 is similar to fig. 8, but relates to a "simulated auction" embodiment, 
i.e. the auctioneer computer calculates (calculator symbolized as machine in 
centre) an immediate result when bids with indicated time points have been 
received from all participants. A log is prepared at the same time, symbolized by 
the short "film roll" on the right, and the log can be fetched at any time later by the 
participant 

This is the auction version for participants who want full freedom in 
choosing their own time for participation - without having to wait through the 
auction process, or a set bid-time or auction time. The beauty (from the 
organizer's point of view) of this auction is that it is an auction totally flexible as 
concerns fulfilling market demand, as one auction starts as soon as the previous 
is finished. 
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This simulated auction is non-interactive, with limited number of 
participants. Participants are signing on/purchasing bids, and bidding individually 
up to a flexible starting time (when the pre-set number of participants have signed 
on/bid). 

The number of bids/participants is set before bidders can sign 
on/participate. Therefore, the participant starts immediately when the set number 
of bids is entered, as a genuine off-Iine/non interactive auction. 

The server has, based on number of allowed bids (function of bids per 
participant/participants), created a time simulation string, divided into individual 
blocks with enough individual blocks to allow for space between bids (unused 
blocks), i.e. to allow for any bid in the string to win - at the beginning - middle - 
end). This procedure is a total replica/simulation of the "real-time" auction, save for 
the interactive element I.e. the participants cannot in this auction, react to the 
other participants during the auction. Otherwise the selection criteria for the winn r 
is exactly the same. 

When bids have been made, and all bids have been given in, the auction 
machine will immediately simulate the time, and carry out the auction based on 
bid-input. Thus a winner/winners is/are selected. 

When this is done, the participants may enter the organizer's home page 
and retrieve the auction log and the visualization of the auction. 

Each individual will be able to see his bids on his screen, and how long 
time each bid lasts. Subject to a limited number of bids per player, the whole 
auction may be visualized over a period of 5 minutes. 

Regarding the length of the auction, the actual simulation is instant 
However, a participant will use the time it takes to bid. Total individuality of when 
done. 

Since dependent on a fixed number of bids having been made, the point in 
time when the actual auction is run on the auction-machine is not known. 

This auction may be played at any time, but may have a delay in selection 
of winner. 

Sine time is simulated, th problem of 1* bid does not appear. There will 
always be a first bid. Then th auction starts. 
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A bid wins as long as n other bids coming in within a set number of 
seconds. At th outset this time is planned set at 30 seconds. 

The simulation of seconds between bids is done by allocating a number of 
seconds to each block (position where bids are allowed). Since there are more 
5 blocks in a time-string (the total auction time) than bids allowed, there may be 
open spaces/blocks between two bid representing 30 seconds, and thus a winner 
may appear before auction time end. The trick is to estimate number of blocks 
relative to number of bids, to allow for both a winner at the beginning/middle and 
end (last bidder), subject to total bidding strategy. 
10 Such protection may be an issue if a participant can manipulate the auction 

machine before auction starts. When time-simulation/auction winner is calculated, 
this is done off-line, i.e. no jamming/manipulation is then possible from outside 
sources. 

Optional features: 

15 As this auction embodiment is totally non-interactive and off-line with the 

auction machine, the interactive feature of the other auctions is non-existent It 
may however be provided with extra features to give a semblance of interactivity. 
(See below). 

One or more of the below items should be present in the auction for 
20 attractiveness and entertainment value: 
• Simulated Interactivity 

The auction is totally non-interactive in all phases. However, one may 
create, as earlier mentioned, a semblance of interaction, with pop-up theme during 
individual play, exactly the way as described under "Simulation 2", see below. 
25 • Design 

The purely entertaining features are the background design visualizing the 
action of the participants via theme-stories. The story will be simpler than the "real 
time" version (during the placing of bids), and cannot reflect interactively the action 
on the graphical "bid-board", as bidding is done over a period of (say) 15 minutes. 
30 It is however, important to give an impression of interactivity or at least 

action. 
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This cannot be done by interacting with other bidders' actions however, as 
this would be misleading (there will always be some participants who have not yet 
placed their bids - thus affecting strategy for an individual participant after 
individual participant made his bid). Thus the theme design must interact with 
other parameters than actual bidding. One may bring his individual log from a 
previous auction, to guide current bidding as well as background story. 

Another feature is that a participant may choose from a range of 
background stories, the one to his liking, which gives him/her most excitement, or 
alternatively drop the theme stories altogether to concentrate 100% on the bidding 
process. 
• Strategy 

Same as in "real time" embodiment 

A limited number of participants give high winning chances compared to 
most other game types, thus giving a high attraction value. 
Market segmentation: 

1* tier segmentation : Access to PC. 

2 nd tier segmentation : Cost of bids (i.e. covers affluent and average 
segment based on this variable), and limited/no time for playing a "real time" 
auction. 

C) SIMULATION 2 - Non interactive/perceived (partly) inter active, see fig in , 

Fig. 10 represents an embodiment that is an intermediate solution in 
relation to what is shown in figs. 8 and 9. The participants really do not engage in 
an interactive auction, but have nevertheless a specified time period, symbolized 
by the two docks, during which to place their bids in time. The "broken" film roll 
symbolizes the non-interactive bidding during the bid period. The machine on the 
right side symbolizes instant calculation of the auction result after expiry of the 
bidding period, and the short 'film roll" on the far right is a log that can be fetched 
at any later time. 

This type of simulated auction is non-interactive, with unlimited number f 
participants. Participants are signing on/purchasing bids individually up to a pre- 
set starting time, but bidding during an interval of a limited time (bid-time). 
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When numb r of bids/participants is known (at starting point), the auction 
s rver makes a tim simulation string, divided in individual blocks (simulating an 
auction), with enough individual blocks to allow for space between bids (i.e. allows 
for any bid in the string to win, as there may be gaps between each bid so that 
5 any bid may win - either at the beginning/middle or end). 

The participants are allowed 10/15 minutes to use their bids in the string - 
which may be visualized multi-dimensionally for easy bidding on a coupon. 

When the bids have been entered (within the allowed bid period), the 
auction machine will immediately/instantly simulate the time (auction), and come 
10 up with a winner/winners. 

The auction will be visualized immediately when the winner has been 
"calculated", via a meter showing bid activity on a time axis, with the individuals' 
bids entered. Each individual will see his bids on his screen, and how long each 
bid lasts. Subject to a limited number of bids per participant, the whole auction 
15 may be visualized over a period of approx. 5 minutes no matter how many 
participants are participating. 

The length of the auction is independent of the number of participants/bids. 
Fixed time for bidding (on-line, non-interactive). Total auction time including 
visualization may be approx. 15/20 minutes. 

A benefit of this auction embodiment is that a participant not having time for 
"Real time" participation (or wanting a second auction, after "real time" play) may 
enter this auction. 

Since time is simulated, the problem of 1" bid does not appear. There will 
always be a first bid. Then the auction starts. 

A bid wins as long as no other bids are coming in within a set number of 
seconds. At the outset this time is planned set at 30 seconds. The simulation of 
seconds between bids, is done by allocating a number of seconds to each block 
(position where bids are allowed). Since there are more blocks in a time-string (the 
total auction time) than bids allowed, there may be open spaces/blocks between 
two bids representing 30 seconds, and thus a winner may appear before auction 
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end. Th trick is to estimate number of blocks relative to number of bids, to allow 
for both a winner at the beginning/middle and nd (last bidder), subj ct to total 
bidding strategy. 

Jamming/unauthorized acccess - protection 

Such protection may be an issue if a participant can manipulate the auction 
machine before auction starts. 

When a time-simulation/auction winner is calculated, this is done off-line, 
i.e. no jamming/manipulation is possible from outside sources. 
Optional features: 

All of the three below items will have (be perceived as having) 
entertainment value for the participants and set the auction above other game 
types: 

• Interactivity 

• Design 

• Strategy auction (log - analysis of individual strategy compared to other 
participants/winner after auction ends - or alternatively during auction) 

• Interactivity 

The auction is not interactive in the normal sense (like the "real tim " 
version), however, this is an auction alternative for individuals not having time for 
the fully interactive version Since the auction is played (bids placed) during a pre- 
set period, and the auction is visualized in "amended real time" the participants 
will perceive the auction as if they were participating interactively during the 
viewing/visualization. 

• Design 

The purely entertaining features are the background design visualizing the 
action of the participants via theme-stories. The story will be simpler than the "real 
time" version (during the placing of bids), and cannot reflect interactively the action 
on the graphical "bid-board", as bidding is done over a period of (say) 15 minutes. 

It is however, important to give an impression of interactivity or at least 
action. This cannot b done by interacting with other bidders' actions however, as 
this would be misleading (there will always be some that have not yet placed their 
bids - thus affecting strategy for an individual participant after he has made his 
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bid). Thus the theme design must interact with oth r parameters than actual 
bidding. One may bring his individual log from a previous auction, to guide current 
bidding as well as background story. 

Another feature is that a participant may choose from a range of 
background stories, the one to his liking, which gives him/her most excitement, or 
alternatively drop the theme stories altogether to concentrate 100% on the bidding 
process. 
•Strategy 

Same as in "real time" embodiment. 
• Pot/winning chances 

The unlimited number of participants gives lower winning chances than the 
"real-time" auction, however, on the other side, the pot may be very much higher. 
Market segmentation: 

1*tier seg mentation : Access to PC. 

2 nd tier segmentation: Cost of bids (I.e. covers affluent and average 
segment based on this variable), and limited time for playing. 

LEVELS OF SCREEN ACTIVITIES 

(VISUALIZATION): The visual story on the screen (theme) as experienced by a 
participant needs to be created as interactive, with actions interacting on different 
levels with auction activities. It will be basically four levels which should be 
individually interacting as follows, and a fifth "just for fun": 

• The setting (general theme) 

• The auctioneer 

• The general participant population ("competitors" - everyone but you) 

• The individual participant (feedback on individual action) 

• Funny "pop-ups" (sit-com) - (randomly distributed throughout the auction), just 
for fun, as well as a "confusion element" 
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FACTS/INFO TO PARTICIPANTS DURING AUCTION: 

Particularly in a real tim computer network auction embodiment, but also 
in simulation embodiments, the following information will be of interest for the 
participants, and any or all of the features listed below should be transmitted to 
the participants PC's: 

• Timing of bid-round (Fixed, random or sequential) - It Is believed that the 
random alternative is most exciting, where the count-down meter (to winning) 
shifts randomly from 30 sec to 20 sec to 15 sec during the auction. This will 
heighten the excitement, and necessitate higher concentration throughout the 
auction. 

• Each bid's individual life 

• Traffic (how many bids entered during a time sequence/period) 

• Number of bids left (total and individual) 

• Number of bids placed (total and individual) 

• Total number of bids (total and individual) 

• Number of participants 

• Pot size 

LOG PARAMETERS: The log is intended to be a guide for the participants, 
informing them of their actions/ non-actions and how it affects their winning 
chances. The log will also inform them of their strategy compared to 
optimal/winning strategy, and give suggestions for alternative strategies which 
may help them in next auction, hence giving a feeling of winning chances "no 
matter whether I was not winning this time". The auction log will be accessible 
after the auction is over. We expect the auction log also to have an independent 
entertainment value, and can be visualized on the participant PC screens. 
The following elements will be (considered to be) included in the log: 

• You are the Winner 

• Time each bid lasted (before competitive bid placed) 

• Time alt bids lasted 

• How many rounds stayed cool ("wait" position at th nd of a round/total 
accumulated rounds) 
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• How many times stayed cool (accumulated) 

• How many times sam strategy as others (acting within sam "s cond'as 
others, and how many others 

• How many times different strategy (define "different 1 ) 
5 • Optimal strategy vs. your strategy 

• Winner's strategy vs. your strategy 

• Alternative winning .strategies in this auction (good advice for next game) 

IDEAS FOR THEMES: As example of alternative themes: 
10 • Auction with "Einstein" personifying an auctioneer 

• Auction on a Steamboat on Mississippi (1870'ish) 

• Auction on a castle in Scotland 

• "Indiana Jones" - obstacle course - live/die (Searching for the Holy Grail) 

• Traditional auction (with sit-com pop-ups) 
15 • Casino environment/high society 

• Straight auction coupon (as Lotto), the M no fuzz" version for Simulation auctions 

• Etc. 



SIT-COM/POP-UPS: The sit-coms could be a special, recognizing feature for 
20 the organizer's auctions, (example Gary Larson's 'The Far Side") and could also 
be used for advertisement during the auction. The idea would be continuously 
creating new pop-ups. 

The pop-ups confuse the participant as well as provide the auction with 
added entertainment value. They must be so interesting and comic that they 
25 interfere with participant concentration, but makes the auction more fun to 

participate in (as a compensation for loss of concentration - and possibly loss of 
the auction, even). Randomly appearing sit-coms should appear not too often, and 
should appear/disappear in say 5/6 sec. 

The pop-ups can both appear in "real-time*', and particularly in the 
30 Simulation versions of the auction, to make thos more"int motive" and 
int resting/ entertaining. 
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Fig. 11 shows, in a g neral manner and simitar to fig. 1, the various 
parties/objects that may be involved in an auction system according to the 
invention. Two or more objects may be interconnected in open or closed 
communication that may be analogue or digital. In addition to participant PC-s and 
auctioneer servers, which have been dealt with extensively here above, the 
following possibilities shall be mentioned: 

video/automaton auctions may be realized either with a connection via a 
network to an auctioneer server, or the complete auction system may be realized 
inside such an automaton, the auction type then being one with simulated other 
participants. (Such a free-standing automaton may also be realized in the form of 
a small e.g. palm-held, apparatus.) 

However, an automaton may of course operate as a terminal in a similar 
manner as a PC. 

One way of conducting an auction in accordance with the invention, is in 
connection with a TV or radio show. In such a case, normal TV, text TV or radio 
channels (public or closed-circuit) may be used as one part of the communication 
network, namely for presenting the current real time auction progress for the 
participants, who may e.g. use a telephone network (cellular or public switched 
network) as the network part for bidding, i.e. sending bid messages to the 
auctioneer. Hence, the elements telephone, radio and TV are shown in the 
drawing, along with a telefax which is also a possible interface unit in connection 
with a telephone network. It should also be noted that in a digital television 
network, two-way communication will be possible, hence providing a possibility for 
TV sets with message return with the aid of touch screens or e.g. hand-held 
remote controls. 

Finally, in e.g. a TV show there will usually be an audience and audience 
persons may also take part as auction participants, then receiving an interface unit 
(radio or wire connected to the auctioneer computer) for entering into a bidding 
session. 
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Fig. 12 shows an example of a "bid board" that can b used in connection 
with an "instant" type auction, see fig. 9, and such a bid board can be presented 
on a PC screen or e.g. an automaton. Placing of bids, i.e. marking specific points 
of time, is made in a simple manner by moving to hour, minute and second 
5 positions In the three scales/dials shown, and confirming when a desirable time 
point has been set. When all allowed bids have been placed, the total bid package 
is sent to the auctioneer by using the "SEND" button. One feature that can be 
included, is an "accumulated bid value", showing the sum value of all bids made 
so far at the moment of entering a bid, to give the participant an idea of the 
10 possible winning pot. 
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PATENT CLAIMS 

1 . An arrangement for implementing a computerized auction for auction 
participants, based upon submittal of stake-supported bids from said auction 
5 participants within pre-established time limits, said arrangement possibly 

comprising a communication network for communication between an auctioneer 
and said participants, characterized in that it comprises 

- computer interface means adapted for presenting bids from the participants, 

- a computer detector means for detecting bids submitted from each 
10 participant, 

- a real or simulated computer clock situated with the auctioneer for marking 
the start and end times for an auction, recording running auction time as well as 
time points for bid detection in said computer detector means, and 

- a computer decision means for deciding on an auction result, the auction 
15 result being a function of the bid time points. 

2. The arrangement of claim 1, characterized in that said decision 
means is adapted to test whether a predetermined time period, or a time period 
variable according to predetermined rules, has passed after the last detected bid 
20 without detection of a new incoming bid, and if this is the case, to identify the 
participant with the last detected bid as an auction winner, and if this is not the 
case during the total auction duration, to identify the participant having submitted 
the last bid before the auction end time, as a winner. 



3. The arrangement of claim 1, characterized in that said interface 
means are computer terminals attached to a real time data-transmitting 
communication network, possibly via modem, and wherein the auctioneer is 
attached to the same network by means of a computer terminal in a similar 
manner. 

4. The arrangement f claim 3, characteriz din that the 
auctioneer clock, the detector means and the decision means are comprised in an 
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auctioneer computer adapted to manage an auction in accordance with 
programmed auction algorithms. 

5. The arrangement of claim 4, characterized in thatthe 
5 auctioneer computer algorithms are adapted to manage bids submitted in real 
time from the participants during the course of the auction, and wherein said 
computer is adapted for possible correction due to transmission delay from the 
computer terminals of the participants. 

10 6. Thearrangementof claims2and 5, characterized in that one 
of said auctioneer computer algorithms is an algorithm for varying the length of 
said time period as function of elapsed auction time or current bid submittal rate 
from all participants. 

15 7. The arrangement of claim 5, characterized in that the 

participant computer terminals and also the communication network are adapted 
for transmission of real time information from the auctioneer computer, in order to 
present to each participant the running auction progress and activity. 

20 8. The arrangement of claim 4, characterized in that the 

auctioneer computer algorithms are adapted to manage bids submitted in a group 
from each participant within a fixed point of time, so that when this point of time 
has passed, said computer can immediately simulate the total course of the 
auction. 

25 

9. The arrangement of claim 8, characterized in that the total 
number of bids during the auction is predetermined, said auctioneer computer 
algorithms being adapted to manage bids submitted from each participant at the 
same time as the participant makes entry for the auction/pays the bids. 

30 

10. The arrangement of claim 8, charact rized in that nolimitisset 
for the total-number of bids during the auction, said auctioneer computer 
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algorithms being adapted to manage a) auction entry/payment of bids from each 
respective participant within a predetermined point of time, b) thereafter - 
calculating the total auction time, i.e. the time span from start to end time, c) 
establishing a time limit for submittal of grouped bid times, from each respective 
5 participant, and (d) subsequent to reception of bids from the participants and 
expiry of said time limit, simulation of the total course of the auction. 

11. The arrangement of any ofclaims 8-10, characterized in that 
said auctioneer computer, participant computer terminals and communication 

10 network are adapted for transmission of information about the simulated course of 
the auction to each respective participant, possibly in the form of a screen 
presentation of the auction course in a real or transformed time scale. 

12. The arrangement ofclaim 7 or claim 11, characterized in that 
15 said auctioneer computer is also adapted to transmit, in accordance with special 

programming, side information to the participant computer terminals, (a) said side 
information being controlled during real time or simulated auction progress by the 
auctioneer clock and possibly by the running auction development, for initiating 
picture/sound presentation or short film of a type which is auction related, 
20 entertaining or distracting, next to or "behind" the auction information, in order to 
increase the auction attraction, and (b) said side information comprising, during 
phases with entry/pay ment/pre-bidding, animations containing entertainment or 
auction related information or possibly advertising. 

25 13. The arrangement of claim 4, characterized in thatsaid 

auctioneer computer comprises a memory for storing a total auction course, so 
that a participant may have data concerning said auction course presented in his 
computer terminal automatically or on request after a finished auction. 

30 14. The arrangement ofclaim 1, characterized in that atleastone 
participant is a genuine participant and a plurality of participants is a number of 
simulated participants, the syst m further comprising audi neer random 
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generator means controlling said number of and bidding times for simulated 
participants in accordance with pred termined random generator algorithms, said 
algorithms containing parameters adjustable so as to tune auction winning 
probability into a range that is compatible with national law. 

5 

15. The arrangement of claim 1 or2, characterized in that 

- part of said communication network is any of a public switched telephone 
network, a cellular network, a computer network and a reverse TV channel 
network, 

10 - said interface means are any of telephones, cellular phones, telefax units, 
computer terminals, and TV sets having two-way communication capabilities, 

- the auctioneer broadcasting any of a radio program, a TV program and a Text 
TV program via another part of said communication network constituted by any of 
a public radio channel, a TV channel and a closed-circuit network, in which 

15 radio/TV/Text TV program real time information is transmitted regarding auction 
progress. 

16. The arrangement of claim 1, characterized in that the interface 
means are coupons to be completed by each participant and sent to the 
auctioneer, a coupon containing information about the desired bid time points for 
20 the participant in question within a pre-established time frame, and with a number 
of bids fixed according to rule and according to stake, said detector means is a 
coupon reader unit, said decision means is a preprogrammed computer attached 
to said coupon reader unit, and said clock is a simulated clock according to which 
the bids from the participants are ordered chronologically, said communication 
network being a public mail network, a telephone network, a telefax network or a 
computer network. 

17. The arrangement of claim 1, characterizedinthatit comprises 
auction means for processing the bids communicated from the participants, 
communicating receipts of said bids and status details of said auction to said 
participants, and determining a winner of said participants based on said bids 
r ceived and communicating said winner to said participants; 
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bidder means for distinctly communicating to said auction m ans distinct 
said bids from respective said participants and processing said receipts of said 
bids and said status details of said auction communicated from said auction 
means; 

5 network means for providing communication transmission paths between 

said auction means and said bidder means, information communicated across 
said network means between said auction means and said bidder means being 
under at least one of a first transport protocol and a second transport protocol, 
said first transport protocol being more reliable than said second transport protocol 
10 with respect to insuring that data representative of said Information arrives at one 
of said auction means and said bidder means, said second transport protocol 
being faster than said first transport protocol with respect to time elapsed for said 
data to be sent across said network means and received by one of said auction 
means and said bidder means, wherein risks associated with said information 
15 communicated under said second transport protocol include loss of said data 
during transmission across said network means, arrival of said data at one of said 
auction means and said bidder means in an order different from a temporal order 
in which said data were sent from respective one of said bidder means and said 
auction means, and duplicates of said data arriving at one of said auction means 
20 and said bidder means, said risks being an aspect of said auction in respect of 
said determining said winner of said participants. 

18. The arrangement according to claim 17, characterized in that 
said bids are communicated from said bidder means to said auction means under 

25 said second transport protocol. 

19. The arrangement according to claim 17, characterized in that 
said auction means comprises auctioneer means for processing said bids 
communicated from said bidder means and communicating said receipts of said 

30 bids and said status details of said aucti n to said bidder means, said auctioneer 
means communicating with said bidder means under said second transport 
protocol. • 
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20. Th arrangement according to claim 19, characterized inthat 
said auction system comprises administrative means for processing accounts of 
said participants and processing information related to said auction apart from 
5 information communicated between said auctioneer means and said bidder 
means. 



21. The arrangement according to claim 20, characterized in that 
said administrative means further comprises means for processing content in a 

10 form of World Wide Web pages communicated to and from said bidder means. 

22. The arrangement according to claim 20, characterized in that 
said auction means includes auction support means for prompting said auction 
means to begin said auction, said auction support means communicating with said 

15 administrative means on a secure communications channel over a transmission 
path that is one of outside said network means and through said network means. 

23. The arrangement according to claim 22, characterized in that 
said auction support means further comprises means for storing results of said 
auction. 



20 



25 



24. The arrangement according to claim 22, characterized in thatsaid 
auctioneer means and said auction support means together comprise a first computer 
network server coupled to said network means, and said adiriiiiistative means comprises a 
second computer network server coupled to said network means. 



25. The arrangement according to claim 17, characterized in that 
said network means comprises at least one of a telephone network, a public mail 
network, a telefax network, a local area network, and the Internet, said first 
transport protocol comprises a Transport Control Protocol/Internet Protocol 
30 (TCP/IP), and said second transport protoc I comprises a User Datagram Protocol 
(UDP). 
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26. The arrangement according to claim 21, characterized in that 
said network means comprises the Internet, said first transport protocol comprises 
a Transport Control Protocol/Internet Protocol (TCP/IP), and said second transport 
protocol comprises a User" Datagram Protocol (UDP). 

5 

27. The arrangement according to claim 26 characterized in that 
said auctioneer means communicates with said bidder means under said UDP, 
said administrative means communicates with said bidder means under said 
TCP/IP, and said auction support means communicates with said administrative 

10 means under a secure sockets layer (SSL). 

28. The arrangement according to claim 19, characterized in that 
said bidder means communicate with said auctioneer means under auction 
protocols layered on top of one of said first and second transport protocols. 

15 

29. The arrangement according to claim 28, characterized in that 
said auction protocols comprise auction administration and bidding protocols. 

30. The arrangement according to claim 29, characterized in that 
20 said auction administration protocols include parameters comprising names of 

said participants, identification of access communication ports to said auctioneer 
means by said bidder means for respective said participants, identification of said 
winner of said participants, time reference for said auction, time when said auction 
is to start, time when said auction is to be finished, time when a current one of 
25 said bids becomes a final bid, number of accumulated said bids at any one time, 
number of said bids a particular one of said participants has left to submit in said 
auction, and how long a particular one of said bids must remain highest of said 
bids to become a winning one of said bids. 

30 31. The arrangement according to claim 29, characteriz d in that 
said bidding protoc Is include parameters comprising a value for each of said 
bids, counts of messages r ceived by said auctioneer means from said bidder 
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means f r each of said participants, notions of time of said auction by each of said 
bidder means, identification of winner of said participants, time when said auction 
started, time when said auction is over and a current one of said bids becomes a 
final bid, number of said bids communicated to said auctioneer means at any one 
5 time, number of bids each of said participants has left, how long one of said bids 
must survive to win in said auction, and number of said participants. 

32. A server for processing bids from auction participants in an arrangement as 
defined in claim ^characterized in that it comprises: 
10 means for processing bids communicated from the participants of an 

auction across a computer network,, 

means for communicating information across said computer network to said 
participants in response to said bids communicated from said participants, 

means for determining a winner of said participants based on said bids 
15 received across said computer network; 

means for communicating across said computer network said winner to 
said participants; 

means for a first transport protocol under which said means for 
communicating information and said winner are earned out; and 
20 means for a second transport protocol under which said bids are 

communicated across said computer network from said participants, 
communications under said first transport protocol being more reliable than under 
said second transport protocol with respect to said communications arriving at 
their destination, communications under said second transport protocol being 
15 faster than under said first transport protocol in respect of time from initially 

transmitting said communications to arrival of said communications at an intended 
destination, wherein risks associated with communicating under said second 
transport protocol include loss of said bids during transmission across said 
computer network, arrival of said bids from different ones of said participants 
0 being in an order different from a temporal order in which said bids were sent from 
respective nes of said participants, and duplicates fat least one f said bids 
arriving at an intended destination, said risks being an aspect of said auction in 
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respect of said means for det mining said winner of said participants, 

33. The server according to claim 32, characterized in that itfurther 
comprises administrative means for processing accounts of said participants. 

5 

34. The server according to claim 33, characterized in that said 
administrative means further comprises means for processing content in a form of 
World Wide Web pages communicated to and from said bidder means. 

10 35. Theserver according to claim 32, characterized in that said 
first transport protocol comprises a Transport Control Protocol/Internet Protocol 
(TCP/IP), and said second transport protocol comprises a User Datagram 
Protocol (UDP), 

15 36. The server according to claim 32, characterized inthat said bids 
are communicated from said participants under auction protocols layered on top of 
one of said first and second transport protocols. 

37. The server according to claim 36, characterized in that said 
20 auction protocols comprise auction administration and bidding protocols. 

38. Theserver according to claim 37, characterized in that said 
auction administration includes parameters comprising names of said participants, 
identification of access communication ports to said auctioneer means by said 
bidder means for respective said participants, identification of said winner of said 
participants, time reference for said auction, time when said auction is to start, 
time when said, auction is to be finished, time when a current one of said bids 
becomes a final bid, number of accumulated said bids at any one time, number of 
said bids a particular one of said participants has left to submit in said auction, and 
how long a particular one of said bids must remain highest of said bids to become 
a winning one of said bids. 
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39. Thes rver according to claim 32, c h a r a c t rized in that said 
bidding protocols include parameters comprising a value for each f said bids, 
counts of messages received by said auctioneer means from said bidder means 
for each of said participants, notions of time of said auction by each of said bidder 
means, identification of winner of said participants, time when said auction started, 
time when said auction is over and a current one of said bids becomes a final bid, 
number of said bids communicated to said auctioneer means at any one time, 
number of bids each of said participants has left, how long one of said bids must 
survive to win in said auction, and number of said participants. 

40. A method for implementing an auction using an arrangement as defined in 
claim 1, characterized in that it comprises the steps of: 

presenting to an auctioneer bids from the participants via at least 
interface means, 

detecting by auctioneer bid detector means bids submitted from any 
participant, 

using a real or simulated clock situated with said auctioneer for marking 
start and end times for said auction, and for recording running auction time as well 
as time points for bid detection by said auctioneer bid detector means, and 
deciding on an auction result by an auctioneer decision means, the 
auction result being a function of the bid time points. 



41. The method of claim 40, characterized in that itfurther 
comprises testing whether a predetermined time period, or a time period variable 
25 according to predetermined rules, has passed after the last detected bid without 
detection of a new incoming bid, and if this is the case, identifying the participant 
with the last detected bid as an auction winner, and if this is not the case during 
the total auction duration, identifying the participant having submitted the last bid 
before the auction end time, as a winner. 

30 

42. The method of claim 40, further characterized by 

communicating bids by input computer equipment of respectiv participants 
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of an auction across a network to auction computer equipment- 
processing received said bids by said auction computer equipment; " 
providing by said auction computer equipment across said network receipts 
of said bids to said input computer equipment; 
5 determining by said auction computer equipment a winner of said 

participants based on said bids received from said input computer equipment; and 

communicating by said auction computer equipment to said input 
computer equipment said winnerof said participants; 

providing first and second transport protocols under which 
10 communications between said auction computer equipment and said input 
computer equipment are earned out, said first transport protocol being more 
reliable than said second transport protocol with respect to said communications 
arriving at an intended destination, said second transport protocol being faster 
than said first transport protocol with respect to time elapsed for said 
15 communications to be sent across said network and received by at least one of 
said input computer equipment and said auction computer equipment, wherein 
risks associated with said communications under said second transport protocol 
include loss of said communications in said network, arrival of said 
communications at one of said auction computer equipment and said input 
20 computer equipment in an order different from a temporal order in which said 
communications were sent from respective one of said input computer equipment 
and auction computer equipment, and duplicates of said communications arriving 
at one of said auction computer equipment and said input computer equipment, 
said risks being an aspect of said auction in respect of said determining said 
25 winner of said participants. 

43. The method according to claim 42, characterized in that it 
further comprises processing accounts of said participants. 

30 44. The method according to claim 42, characterized in that it 
further comprises storing results of said auction. 
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45. Th method according to Iaim42, charact r ized i n t h a t said 
network comprises one of a public mail network, a tei ph ne network, a telefax 
network, and a computer network. 

5 46. Themethod according to claim 42, characterized in that said 
network comprises the Internet, said first transport protocol comprises a Transport 
Control Protocol/Internet Protocol (TCP/IP), and said second transport protocol 
comprises a User Datagram Protocol (UDP). 

10 47. The method according to claim 42, characterized in that it 
further comprises carrying out communications related to said bids between said 
auction computer equipment and said input computer equipment under auction 
protocols layered on top of one of said first and second transport protocols. 

15 48. The method according to claim 47, characterized in that said 
auction protocols comprise auction administration and bidding protocols. 

49. The method according to claim 48, characterized in that said 
auction administration protocols include parameters comprising names of said 

10 participants, identification of access communication ports to said auctioneer 
means by said bidder means for respective said participants, identification of said 
winner of said participants, time reference for said auction, time when said auction 
is to start, time when said auction is to be finished, time when a current one of 
said bids becomes a final bid, number of accumulated said bids at any one time, 

5 number of said bids a particular one of said participants has left to submit in said 
auction, and how long a particular one of said bids must remain highest of said 
bids to become a winning one of said bids. 



50. The method according to claim 48, characterized in that said 
30 bidding pr tocols include parameters comprising a value for each of said bids, 
counts of messages received by said auctioneer means from said bidder m ans 
for each of said participants, notions of time of said auction by each of said bidder 
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means, identification of winner of said participants, time when said auction started, 
time when said auction is over and a current one of said bids becomes a final bid, 
number of said bids communicated to said auctioneer means at any one time, 
number of bids each of said participants has left, how long one of said bids must 
5 survive to win in said auction, and number of said participants. 

51 . The method according to claim 40, further characterized by 
processing in a computer-network server bids communicated from 
participants of an auction across a computer network, 
0 communicating from said server information across said computer 

network to said participants in response to said bids communicated from said 
participants, 

determining in said server a winner of said participants based on said bids 
received across said computer network; 
> communicating from said server across said computer network said 

winner to said participants; 

communicating from said server across said computer network under one 
of a first transport protocol and a second transport protocol, arrival of 
communications at an intended destination being more reliable but slower under 
said first transport protocol than under said second transport protocol, risk of 
communications being lost, delayed and duplicated under said second transport 
protocol being an aspect of said auction in respect of determining said winner of 
said participants. 



52. The method according to claim 51, characterized in that said 
first transport protocol comprises a Transport Control Protocol/Internet Protocol 
(TCP/IP), and said second transport protocol comprises a User Datagram Protocol 
(UDP). 



30 53. The method according to claim 51, characterized inthat said 
bids ar communicated from said participants und r auction prot cols layered on 
top of one of said first and second transport pr tocols. 



CA 02311353 2000-05-23 



AMENDED SHEET 



WO 99/27476 



CA 02311353 2000-05-23 



PCT/NO98/00348 



1/12 



Network server 




^Network server PC 



Fig.1 



CA 02311353 2000-05-23 



WO 99/27476 

PCT/NO98/00348 



2/12 




CA 023II353 2000-05-23 




CA 02311353 2000-05-23 



WO 99/27476 

PCI7NO98/00348 



4/12 



CA 02311353 2000-05-23 



WO 99/27476 PCT/NO9W0348 



5/12 

AUCTION RULES 



PRELIMINARIES 



* 

STARTUP 







PL 


AY 



PAYOFF 



FIG. 5 



CA 02311353 2000-05-23 



WO 99/27476 



PCT/NO98/0034S 



6/12 



Logon/Quit (TCP) 












Accept/Payoff (TCP) 










Client 

Bid fUDP) 




Game Engine 




Receipt/Status (UDP) 










/ Plavers \ 










f Log \ 









FIG. 6 



CA 023H353 2000-05-23 




FIG. 7 



CA 02311353 2000-05-23 




CA 02311353 2000-05-23 

WO 99/27476 



PCT/NO98/00348 



9/12 




CA 02311353 2000-05-23 



WO 99/27476 

PCT/NO98/0Q348 



10/12 



CA 02311353 2000-05-23 

WO 99/27476 



PCI7NO98/00348 



11/12 
Audtenca/partfclpanti 




Fig. 11 



* t , 1 



CA 02311353 2000-05-23 



PCT/NO98/00348 



12/12 




Fig. 12 



